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1.  INTRODUCTION 


1.1  PURPOSE  OF  REPORT 

Despite  the  trend  toward  computerization  in  the  transit  industry,  many 
systems  still  utilize  manual  methods  for  collecting  and  analyzing  information 
related  to  security  incidents.  These  manual  methods  do  not  promote  the  easy 
identification  of  recurring  security  problems  and  the  initiation  of  a suitable, 
timely  response.  Due  to  the  increasing  availability  and  affordability  of 
microcomputers,  transit  systems  now  have  an  excellent  opportunity  to  improve 
their  efficiency  in  this  area. 

This  report  describes  a microcomputer-based  Security  Incident  Reporting 
System  (SIRS)  developed  to  provide  the  transit  industry  with  a means  of 
enhancing  passenger  security.  Demonstrated  at  the  Metropolitan  Transit 
Commission  (MTC)  in  Minneapolis,  MN,  the  SIRS  program  is  used  to  record  security 
incident  information  and  produce  standard  statistical  reports.  The  system  can 
be  queried  to  provide  security-related  statistics  upon  request,  and  individual 
security  incident  reports  can  be  retrieved  for  inspection. 

Although  demonstrated  at  MTC,  SIRS  was  designed  to  meet  the  requirements  of 
transit  bus  systems  in  general.  Because  of  its  flexible  structure,  SIRS  can  be 
modified  to  meet  the  varying  input  and  output  requirements  of  other  bus  systems. 
This  report  provides  an  overview  of  the  development  of  SIRS  and  its 
demonstration  at  MTC,  and  is  designed  to  acquaint  the  reader  with  the 
capabilities  of  the  SIRS  system.  More  detailed  information  on  the  operation  of 
SIRS  is  contained  in  the  SIRS  Users’  Manual,  available  upon  request  from  the 
Transportation  Systems  Center. 

1.2  NEEDS  OF  THE  INDUSTRY 

Data  collection  and  analysis  are  essential  parts  of  maintaining  and 
improving  transit  security  operations.  The  availability  of  reliable  data  allows 
a transit  system  to  assess  the  extent  of  security  problems,  to  detect  trends  in 
security  incidents  over  time,  and  to  evaluate  the  effectiveness  of  security 
countermeasures.  In  addition,  such  data  assist  in  the  efficient  deployment  of 
security  personnel  by  identifying  high  crime  locations. 
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On  an  industrywide  level,  security  data  collection  by  local  transit  systems 
represents  an  initial  step  toward  the  development  of  an  industrywide  reporting 
system.  Such  a reporting  system  would  be  useful  for  assessing  national  trends 
in  security  incidents,  for  developing  solutions  to  generic  transit  security 
problems,  and  for  sharing  information  on  the  effectiveness  of  security 
countermeasures  thoughout  the  industry. 

1.3  DATA  AUTOMATION  IN  THE  TRANSIT  INDUSTRY 

The  level  of  automation  associated  with  data  collection  and  analysis 
functions  varies  throughout  the  industry.  At  present,  however,  the  use  of 
automation  is  increasing  at  a rapid  rate.  Many  systems  have  automated  payroll 
and  accounting  functions.  Automation  presents  transit  systems  with  the 
advantages  of  improved  data  access,  ability  to  analyze  large  quantities  of  data 
quickly,  and  increased  capacity  for  storing  large  amounts  of  data.  The  extent 
to  which  security  incident  data  collection  is  automated  parallels  the  general 
level  of  automation  within  the  industry. 

The  increasing  availability  of  microcomputers  presents  advantages  in  the 
automation  of  transit  system  data.  The  cost  of  acquiring  the  necessary  hardware 
and  software  is  within  the  reach  of  most  systems,  and  the  skills  necessary  to 
operate  the  system  can  be  acquired  by  existing  personnel. 

1.4  TRANSIT  SECURITY  DATA  COLLECTION  PRACTICES 

1.4.1  Scope  of  Data  Collection  Activities 

Transit  security  data  collection  was  the  subject  of  a recent  study 
sponsored  by  UMTA  (Hargadine  and  Scott,  1985).  The  findings  of  this  study 
indicate  that  the  extent  and  type  of  data  collection  varies  according  to  the 
size  of  the  system  and  the  functions  that  its  security  department  performs. 

In  terms  of  security  operations,  transit  systems  generally  rely  on  one  of 
the  following  types  of  security  forces: 

1.  An  in-house  police  force; 

2.  A dedicated  unit  of  the  municipal  police  force; 
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3.  Contracted  private  security  coverage; 

4.  No  security  coverage  except  for  municipal  police  backup. 

Large  transit  systems  tend  to  have  their  own  police  force  or  a dedicated 
municipal  unit,  while  smaller  systems  often  contract  for  private  coverage  or 
have  no  security  coverage  except  for  municipal  police  backup. 

The  type  of  security  incident  information  collected  depends  to  a large 
extent  on  the  type  of  security  operation  involved.  Most  systems  gather  basic 
data  such  as  incident  type  and  frequency  as  a means  of  tracking  overall  trends 
in  transit  crime.  Systems  involved  in  deploying  their  own  security  or  police 
officers  typically  collect  data  on  time  and  location  of  security  incidents  in 
order  to  most  efficiently  allocate  these  personnel.  Systems  responsible  for 
apprehending  and  prosecuting  suspects  need  further  information,  such  as  suspect 
descriptions,  names  and  addresses  of  victims  and  witnesses,  as  well  as 
circumstances  surrounding  an  incident. 

1.4.2  Data  Collection  Sources 

Transit  systems  collect  information  on  security  incidents  from  a variety  of 
sources,  some  of  which  are  listed  below: 

1.  Bus  drivers  - Since  drivers  are  usually  present  at  the  scene  of  an 
incident,  they  are  a primary  source  of  information.  Most  systems 
require  drivers  to  fill  out  a report  on  any  significant  incident 
occurring  during  their  shift. 

2.  Dispatchers  - When  drivers  call  into  a control  center  to  request 
assistance,  the  dispatcher  records  information  on  the  incident. 
Dispatchers  are  often  required  to  submit  incident  reports. 

3.  Security  officers  - These  officers  are  often  required  to  submit  reports 
describing  incidents  which  they  have  handled  on  their  shift. 

4.  Police  officers  - Municipal  police  called  to  the  scene  of  an  incident 
submit  incident  reports  to  their  own  department.  These  reports  are 
usually  available  to  transit  systems  upon  request. 

5.  Damage  reports  - Maintenance  personnel  at  many  transit  systems  are 
required  to  submit  reports  on  the  extent  and  cost  of  vandalism-related 
damage . 
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6.  Customer  complaints  - Formal  customer  complaints  sometimes  relate  to 
security  incidents  witnessed  on  the  transit  system. 

Transit  systems  rarely  use  all  of  these  sources  in  their  security  data 
collection  procedures.  The  types  and  number  of  sources  used  will  affect  how 
information  is  input  into  a security  incident  reporting  system  like  SIRS. 
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2.  APPROACH  TO  SIRS  DEVELOPMENT 


SIRS,  although  a generic  system,  was  developed  to  address  the  requirements 
of  the  Metropolitan  Transit  Commission  (MTC)  in  Minneapolis,  MN.  The  following 
sections  provide  an  overview  of  MTC  transit  operations  and  the  structure  and 
function  of  its  security  department. 

2 . 1 BACKGROUND 

The  Metropolitan  Transit  Commission  was  created  by  the  State  of  Minnesota 
in  1970  as  the  result  of  the  public  takeover  of  a private  carrier.  At  that 
time,  MTC  also  assumed  a coordinating  role  for  smaller  private  transit  companies 
operating  in  the  area.  MTC  is  one  of  the  largest  all-bus  systems  in  the 
country,  operating  approximately  810  buses  on  a daily  basis.  MTC  also  operates 
40  paratransit  vehicles.  The  MTC  system  encompasses  a seven-county  area  around 
Minneapolis  and  St.  Paul,  and  operates  in  some  95  smaller  cities  and 
jurisdictions. 

The  MTC  Security  Department  staff  consists  of  a chief  of  security,  a part- 
time  security  coordinator,  and  a part-time  student  intern.  In  addition,  MTC 
employs  60  part-time  security  officers  to  patrol  the  bus  system.  The  security 
officers  are  drawn  from  the  ranks  of  off-duty  Minneapolis  and  St.  Paul  municipal 
police  officers.  The  security  coordinator,  also  an  off-duty  officer,  is 
responsible  for  deploying  these  officers  on  the  bus  system.  Every  two  weeks, 
officers  are  assigned  to  specific  bus  routes  for  4-hour  shifts.  The  part-time 
student  intern  is  responsible  for  inputting  data  to  SIRS  and  generating  reports 
from  the  system. 

2.2  MTC  SECURITY  INCIDENT  REPORTING  PROCEDURES 

Security  incident  information  for  incorporation  into  the  SIRS  database  is 
gathered  from  four  sources: 

1.  Dispatcher  Special  Situation  Reports; 

2.  Bus  driver  Special  Incident  Reports; 

3.  Security  officer  duty  reports; 

4.  Municipal  police  incident  reports. 
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Figure  2-1  represents  an  overview  of  SIRS,  showing  the  sources  of  input  data  and 
the  output  reports  produced. 

When  a driver  calls  into  the  Transit  Control  Center  requesting  assistance, 
the  dispatcher  fills  out  a "Special  Situation  Report”  describing  the  incident  in 
question.  Requests  for  assistance  are  made  in  response  to  security  incidents 
and  other  situations,  such  as  accidents,  mechanical  problems,  injury,  and 
sickness.  All  Special  Situation  Reports  are  sent  to  the  MTC  Security  Department 
on  a regular  basis. 

Drivers  must  fill  out  a "Special  Incident  Report”  for  any  significant 
incident  they  witness.  Usually  the  Control  Center  asks  the  driver  to  fill  out 
such  a report  when  an  incident  is  called  in.  In  cases  where  incidents  were  not 
called  into  the  Control  Center,  the  garage  manager  may  request  that  drivers 
complete  such  reports,  or  drivers  may  fill  out  reports  on  their  own.  All 
Special  Incident  Reports  are  collected  and  sent  to  the  Security  Department. 

Security  officers  involved  in  handling  a security  incident  are  required  to 
describe  the  incident  on  their  duty  sheets,  which  are  sent  to  the  Security 
Department  on  a weekly  basis. 

In  cases  where  the  municipal  police  have  been  called  to  the  scene,  the 
Security  Department  will  request  a copy  of  the  police  report  on  the  incident 
from  the  appropriate  police  department. 

Samples  of  the  four  reporting  forms  used  as  input  to  SIRS  are  presented  in 
the  Appendix. 

2.3  MTC  SECURITY  INCIDENT  CLASSIFICATION 

As  stated  above,  the  MTC  incident  reporting  system  is  designed  to  utilize 
dispatcher  and  bus  operator  reports  which  deal  with  all  reported  incidents, 
security  and  nonsecurity  alike.  As  shown  below,  the  incident  categorization 
schema  used  by  MTC  contains  20  categories,  of  which  the  first  10  are  security- 
related  incident  categories,  and  the  last  10  nonsecurity  incident  categories: 

1.  Fare  evasion  or  dispute; 

2.  Driver  interference  (delay  of  operations); 

3.  Prohibited  activity  (smoking,  eating,  drinking,  loud  radio,  etc.); 
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FIGURE  2-1.  OVERVIEW  OF  SIRS 


4.  Assault,  threat  against  driver; 

5.  Assault,  threat  against  passenger; 

6.  Theft  (property  taken  without  authorization); 

7.  Robbery  (property  taken  from  a person  by  force); 

8.  Vandalism; 

9.  Intoxicated  person  (including  person  asleep  on  bus); 

10.  Miscellaneous  (security-related); 

11.  Miscellaneous  (transportation-related); 

12.  Witness  report  (MTC  or  bus  not  involved); 

13.  Silent  alarm  (life  threatening  or  medical  emergency); 

14.  Silent  alarm  (false); 

15.  Lost/late  service; 

16.  Vehicle  accident; 

17.  Passenger  accident; 

18.  Pedestrian  accident; 

19.  Illness/injury  (driver); 

20.  Illness/injury  (passenger). 

The  SIRS  database  incorporates  all  of  these  categories,  including 
nonsecurity  incidents.  For  purposes  of  analysis,  the  user  can  screen  out  all 
nonsecurity  incidents  when  generating  reports,  so  that  only  security  incidents 
are  included. 
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3.  SIRS  DESIGN 


3.1  SIRS  HARDWARE  AND  SOFTWARE  REQUIREMENTS 

As  deployed  at  the  Metropolitan  Transit  Commission,  SIRS  runs  on  a hardware 
package  consisting  of  an  IBM  Personal  Computer  (PC)  with  256K  memory  and  a 10MB 
hard  disk.  SIRS  can  be  run,  however,  on  any  IBM  PC-compatible  computer  with 
equivalent  memory  and  storage  capacity.  For  systems  as  large  as  MTC,  a 10MB 
hard  disk  is  probably  necessary,  but  for  smaller  systems  less  storage  may  be 
adequate.  Peripheral  equipment  used  at  MTC  in  conjunction  with  the  IBM  PC 
include  a monochrome  monitor  and  a dot  matrix  printer.  MTC  is  planning  to 
purchase  a graphic  board  to  provide  a graphic  capability. 

SIRS  software,  running  under  the  MS-DOS  2.11  operating  system,  is  written 
in  dBASE  III.  The  dBASE  III  software  package  is  a relational  database  system, 
which  includes  its  own  programming  language  and  various  utilities,  such  as  a 
screen  editor  and  a help  function.  When  the  SIRS  application  programming  was 
complete,  a compiler  program,  Clipper,  was  used  to  create  a compiled  version  of 
SIRS.  The  compiled  version  operates  at  greatly  increased  processing  speeds. 

3.2  SIRS  MENU  STRUCTURE 

The  SIRS  program  is  accessed  through  a series  of  menus  and  formated 
screens.  Figure  3-1  shows  an  overview  of  the  SIRS  main  menu  structure  and  the 
various  submenu  functions  available. 

The  submenus  are  accessed  from  the  SIRS  main  menu.  Each  menu  selection  has 
a corresponding  screen.  Once  a screen  has  been  called  up,  the  user  is  prompted 
for  additional  information  to  specify  what  submenu  operation  is  desired.  Using 
the  main  menu  shown  in  Figure  3-2,  the  user  may  select  data  entry/update,  query, 
report  generation,  or  file  maintenance  options. 

3.2.1  Entry/Update  Function 

The  entry/update  function  allows  the  user  to  enter  new  data  as  well  as  to 
update  information  already  in  the  SIRS  database.  Figure  3-3  presents  the 
entry/update  menu.  Although  data  entry  and  data  update  are  similar,  there  are 
differences  in  their  execution.  When  entering  new  data,  the  user  calls  up  the 
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FIGURE  3-1.  SIRS  MENU  STRUCTURE 


SIRS  MAIN  MENU 


0 - EXIT 

1 - ENTRY/UPDATE  MENU 

2 - QUERY  MENU 

3 - REPORT  MENU 

4 - FILE  MAINTENANCE 
ENTER  YOUR  SELECTION  — 


FIGURE  3-2.  SIRS  MAIN  MENU 


ENTRY/UPDATE  MENU 

0 - EXIT 

1 - ENTER  SPECIAL  SITUATION  REPORT 

2 - ENTER  SPECIAL  INCIDENT  REPORT 

3 - ENTER  SECURITY  OFFICER  REPORT 

4 - ENTER  POLICE  REPORT 

5 - UPDATE  USING  SPECIAL  SITUATION  REPORT 

6 - UPDATE  USING  SPECIAL  INCIDENT  REPORT 

7 - UPDATE  USING  SECURITY  OFFICER  REPORT 

8 - UPDATE  USING  POLICE  REPORT 
ENTER  YOUR  SELECTION  — 


FIGURE  3-3.  ENTRY/UPDATE  MENU 


11 


data  entry  screen  and  fills  in  the  blanks  with  new  information.  When  updating 
existing  data,  the  user  must  first  retrieve  the  original  incident  record  and 
then  add  to  or  modify  that  record. 

To  enter  new  data,  the  user  selects  the  data  entry  screen  corresponding  to 
the  input  form  from  which  data  is  to  be  entered.  The  user  transfers  data  from 
the  hardcopy  report  to  the  corresponding  blanks  on  the  screen.  After  data  entry 
is  complete,  the  program  prompts  the  user,  "Do  you  wish  to  enter  this  data? 
(Y/N)."  A "Yes"  response  instructs  the  program  to  enter  the  data  into  the  SIRS 
database,  thus  creating  a new  incident  record.  A "No"  response  returns  the  user 
to  the  entry /update  menu.  Figure  3-4  shows  a data  entry  screen  with  data 
filled  in  for  a Special  Situation  Report. 

The  data  update  function  allows  the  addition  of  new  data  or  the 
modification  of  existing  data  for  a record  already  in  the  SIRS  database.  To 
update  data,  the  original  incident  record  must  be  retrieved  from  the  database. 
For  this  purpose,  the  user  needs  to  know  specific  identifying  information,  such 
as  incident  date,  bus  number,  and  route  number.  If  such  information  is 
available,  the  user  can  use  the  data  update  function  to  retrieve  the  record. 
Figure  3-5  shows  the  data  update  screen  with  identifying  information  entered  in 
the  appropriate  places.  Figure  3-6  displays  the  incident  record  retrieved  from 
the  database. 

If  the  information  on  date,  bus  number,  and  route  number  is  unavailable  or 
its  accuracy  is  in  doubt,  the  query  function,  described  in  the  following 
section,  provides  an  alternative  method  of  locating  the  original  report. 

3.2.2  Query  Function 

The  query  function  has  the  dual  capability  of  retrieving  incident  records 
from  the  database  and  of  providing  statistical  data  upon  request.  As  noted 
above,  the  query  function  can  be  used  to  scan  the  database  and  locate  a specific 
record.  The  user  may  wish  to  locate  these  records  for  data  update  or  for 
retrieving  information  on  a specific  incident. 

To  obtain  statistical  data  using  the  query  function,  the  user  selects  from 
among  the  following  criteria:  date,  time  of  day,  incident  category,  route 
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SPECIAL  SITUATION  REPORT 


INCIDENT  NO  CATEGORY  NO  CATEGORY  TITLE  DATE  DAY  TIME  (A/P) 

1 02  Driver  interference  11/26/85  Tue  06:05  P 

LOC  (CITY)  STPAUL  LOC  (STREETS)  MINNESOTA  AT  8TH  ST 

BUS  NO  DRIVER  NO  ROUTE  NO  RUN  NO  DIR  GARAGE 
0884  1208  -16-S  6233  N SN 

SERVICE  LOST (Y/N)  WHAT?  SERVICE  LATE (Y/N)  TIME? 

PERSONAL  INJURY  (Y/N)  WHO 

DAMAGE  TO  PROPERTY  (Y/N)  WHAT 

TYPE  OF  COMMUNICATIONS  RRTT  PRTT  S/A  PHONE 

PUBLIC  SAFETY  NOTIFIED  POLICE  Y FIRE  MEDIC 

WITNESS  CARDS  REQUESTED  (Y/N) 

REPORTS  REQUESTED  ACCIDENT  INCIDENT  Y DAMAGE 

DESCRIBE  SITUATION  PASSENGER  INTERFERED  WITH  DRIVER  WHILE 

OPERATING  THE  BUS.  POLICE  ARRIVED  AND  ARRESTED  THE  PASSENGER. 


CASE  CONTROL  NO  FIELD  SUPERVISOR  SHOPBELL 

PERSONS  NOTIFIED  DANA  HARRIS 

PREPARED  BY  SCHMIDT  #6  DATE  PREPARED  11/26/85 

DO  YOU  WISH  TO  ENTER  THIS  DATA  (Y/N)? 


FIGURE  3-4.  DATA  ENTRY  SCREEN  FOR  SPECIAL  SITUATION  REPORT 


UPDATE  SPECIAL  INCIDENT  REPORT 
DATE:  11/07/85 

BUS  NO:  0854 

(ENTER  0000  IF  NO  BUS  INVOLVED) 
ROUTE  NO:  1-18-M 

RUN  NO: 


FIGURE  3-5.  DATA  UPDATE  SCREEN 
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SPECIAL  INCIDENT  REPORT 


PAGE  1 OF  2 


INCIDENT  NO  CATEGORY  NO  CATEGORY  TITLE  DATE  DAY  TIME  (A/P) 

1 08  VANDALISM  11/07/85  Thu  12:05  A 

LOC  (CITY)  MPLS  LOC  (STREETS)  WASH  /LOWRY 

BUS  NO  DRIVER  NO  ROUTE  NO  RUN  DIR  GARAGE 

0854  0455  1-18-M  0654  S NI 

SERVICE  LOST (Y/N)  N WHAT?  SERVICE  LATE (Y/N)  N TIME? 

TYPE  OF  COMMUNICATIONS  RRTT  PRTT  Y S/A  PHONE 

SUPERVISOR  ON  SCENE  (NONE/NAME) 

PUBLIC  SAFETY  AT  SCENE  POLICE  FIRE  MEDIC 

PERSONAL  INJURY  (Y/N)  N WHO 

DAMAGE  TO  PROPERTY  (Y/N)  Y WHAT  CRACKED  WINDSHIELD 
OFFENSES  COMMITTED 

OFFENDERS  ARRESTED/ TAGGED  (Y/N)  HOW  MANY  0 

CITIZENS  ARREST  SIGNED  (Y/N)  CHARGES 

WITNESSES  (Y/N)  N WITNESS  CARDS  (NUMBER)  0 

DESCRIBE  SITUATION  SOMEONE  THREW  A ROCK  AND  CRACKED  THE  BUS 

WINDSHIELD. 


number,  run  number,  direction  of  travel,  location,  and  arrest  (yes/no).  The 
user  may  select  any  or  all  of  these  data  elements  as  defining  criteria  for  a set 
of  incidents.  Following  criteria  selection,  the  database  is  searched  for 
corresponding  incidents.  The  total  number  of  such  incidents  is  displayed  on  the 
screen.  Next,  the  user  has  the  option  of  "paging  through"  all  incident  records 
matching  the  selected  criteria. 

An  example  of  a statistical  data  request  might  be  to  determine  the  number 
of  incidents  of  fare  evasion  during  the  month  of  November.  Figure  3-7 
shows  the  query  screen  with  data  entered  to  request  incidents  of  fare  evasion 
(incident  category  "01")  for  the  month  of  November,  1985.  The  number  of 
incidents  matching  these  criteria  (in  this  instance,  30)  is  displayed  at  the 
bottom  of  the  same  screen  after  a search  of  the  database.  The  user  may 
subsequently  view  each  of  the  incident  records  matching  these  criteria. 

3.2.3  Report  Function 

The  report  menu  (Figure  3-8)  allows  the  user  to  select  from  a series  of 


summary  reports. 


INCIDENT  QUERY 


START  DATE  : 11/01/85  END  DATE  : 11/30/85 

START  HOUR  : (A/P)  END  HOUR  : (A/P) 

BUS  NUMBER  : 

ROUTE  NUMBER  : - - 

RUN  NUMBER  : 

CATEGORY  NUMBER  : 01 

NUMBER  OF  INCIDENTS  : 30 

DO  YOU  WISH  TO  DISPLAY  FIRST  INCIDENT  (Y/N)  ? 


FIGURE  3-7.  INCIDENT  QUERY  AND  RESPONSE  FOR  FARE  EVASION 


REPORT  MENU 

0 - EXIT 

1 - ANNUAL  INCIDENT  REPORT 

2 - INCIDENT  REPORT 

3 - BUS  ROUTE  INCIDENT  REPORT  (TIME  PERIOD, DAY-OF-WEEK) 

4 - BUS  ROUTE  INCIDENT  REPORT  (TIME  PERIOD) 

5 - SILENT  ALARM  REPORT 

6 - ARREST  REPORT 
ENTER  YOUR  SELECTION  — 


FIGURE  3-8.  REPORT  MENU 
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The  "Incident  Report"  (Figure  3-9)  summarizes  incidents  by  category;  by 
location  (Minneapolis,  St.  Paul,  suburbs);  by  personnel  handling  the  incident 
(transit  employee,  security  officer,  police  officer);  and  by  whether  the 
incident  resulted  in  personal  injury,  property  damage,  lost  time,  or  arrest. 

The  user  may  select  the  range  of  dates  and  incident  categories  to  be  included  in 
the  report. 

The  "Annual  Incident  Report"  provides  a summary  of  all  incidents  occurring 
during  a given  year  by  incident  category.  Figure  3-10  provides  a sample  annual 
incident  report,  shown  here  as  printed  output  rather  than  as  a screen  display. 


FROM 
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INCIDENT  REPORT 

11/01/85  TO  11/03/85 
CATEGORY  01  TO  05 

PAGE  NO. 
04/01/86 
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INCIDENTS 

1 

1 
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HANDLED  BY 
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RESULTED 

IN 

1 
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TRAN 

SEC 

| PERS 

PROP 

TIME 

GORY  | 
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| TOTAL 

01  | 
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2 0 
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02  | 
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1 
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2 
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0 
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1 1 

0 
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REPORT  COMPLETED  ! 
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any  key 

to 

continue 

* * * 

FIGURE  3-9.  INCIDENT  REPORT 
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ANNUAL  INCIDENT  REPORT  FOR  1985 


PAGE  NO. 
07/15/86 


1 


CAT 

DESCRIPTION 

JAN 

FEB 

MAR 

APR 

MAY 

JUN 

JUL 

AUG 

SEP 

OCT 

NOV 

DEC 

TOT 

01 

Fare  dispute/ evasion 

12 

18 

13 

18 

11 

8 

12 

18 

16 

21 

30 

1 

26  | 
l 

203 

02 

Driver  interference 

7 

15 

11 

16 

3 

3 

4 

3 

10 

17 

9 

1 

6 | 
i 

104 

03 

Prohibited  activity 

5 

28 

14 

66 

37 

65 

70 

77 

84 

158 

158 

i 

141| 

i 

903 

04 

Drvr-assault/ threat 

9 

6 

5 

3 

6 

5 

9 

9 

9 

10 

7 

1 

HI 

i 

89 

05 

Psgr-assault/threat 

7 

7 

7 

10 

9 

17 

7 

12 

4 

6 

13 

1 

2 I 

l 

101 

06 

Theft 
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7 

2 

3 

5 
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1 

0 

1 

1 

1 

6 | 
i 

37 

07 

Robbery 

1 
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0 

1 

1 

0 

0 

2 

0 

4 

4 

1 

o 1 

i 

13 

08 

Vandalism 

3 

19 

27 

28 

23 

20 

19 

32 

22 

28 

29 

1 

17  | 

267 

09 

Intoxicated  person 

20 

38 

35 

52 

26 

19 

36 

44 

41 

50 

72 

1 

70  | 

503 

10 

Misc  security  relatd 

6 

8 

7 

8 

19 

21 

17 

51 

52 

35 

39 

1 

66  | 
i 

329 

11 

Misc  transp.  related 

32 

27 

23 

23 

29 

27 

18 

12 

22 

31 

37 

1 

46  | 

327 

12 

Uninvolved  witness 

5 

9 

6 

2 

12 

12 

8 

8 

10 

6 

8 

1 

9 1 

95 

13 

Silent  alarm,  real 

4 

3 

2 

2 

1 

6 

6 

2 

6 

1 

4 

1 

2 I 

39 

14 

Silent  alarm,  false 

20 

13 

22 

23 

13 

3 

12 

12 

19 

20 

32 

1 

33  | 

222 

15 

Lost/late  service 

35 

32 

31 

24 

38 

10 

22 

4 

13 

15 

48 

1 

33  | 

305 

16 

Vehicle  accident 

64 

35 

61 

30 

28 

29 

31 

37 

39 

43 

71 

1 

87  | 

555 

17 

Passenger  accident 

20 

11 

11 

2 

13 

7 

5 

6 

6 

15 

12 

1 

17  | 

125 

18 

Pedestrian  accident 

2 

1 

1 

2 

4 

2 

5 

1 

2 

0 

1 

4 I 

25 

19 

Illness/ in jury-drvr 

6 

4 

4 

6 

9 

3 

9 

7 

6 

5 

8 

1 

13  | 

I 

80 

20 

Illness/ in jury-psgr 

6 

11 

8 

7 

15 

3 

5 

11 

11 

9 

15 

1 

HI 

1 

112 

TOTALS 

264 

287 

295 

325 

300 

265 

304 

349 

372 

475 

598 

| 

6001 

4434 

FIGURE  3-10.  ANNUAL  INCIDENT  REPORT 
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BUS  ROUTE  INCIDENT  REPORT 
(TIME-PERIOD, DAY-OF-WEEK) 

PAGE  NO.  1 

FROM  11/01/85  TO  11/05/85  04/01/86 

FROM  CATEGORY  01  TO  10 


LOCATION 

TIME 

PERIOD 

DAY-OF-WEEK 

ROUTE  NUMBER 

FREQUENCY 

MPLS 

10:00 

AM 

- 

4:00 

PM 

FRI 

0-21-M 

2 

MPLS 

4:00 

PM 

- 

10:00 

PM 

MON 

0-05 -M 

3 

MPLS 

4:00 

PM 

- 

10:00 

PM 

TUE 

0-05-M 

6 

MPLS 

4:00 

PM 

- 

10:00 

PM 

FRI 

0-17-M 

3 

MPLS 

4:00 

PM 

- 

10:00 

PM 

FRI 

0-05-M 

2 

MPLS 

4:00 

PM 

- 

10:00 

PM 

SAT 

0-05-M 

5 

Press  any  key  to  continue... 


FIGURE  3-11.  BUS  ROUTE  INCIDENT  REPORT 

The  "Bus  Route  Incident  Report"  (Figure  3-11)  summarizes  incidents  by  bus 
route.  The  user  may  select  to  report  on  only  those  routes  with  incident 
frequency  greater  or  equal  to  any  specified  number  "N."  In  addition  to  bus 
route,  these  reports  summarize  incidents  by  time  period  (in  4-hour  segments), 
location,  and  day-of-week.  There  are  two  bus  route  incident  reports,  identical 
except  that  the  first  contains  an  additional  breakdown  by  day-of-week. 

The  "Silent  Alarm  Report"  (Figure  3-12)  provides  a listing  of  all  incidents 
involving  the  use  of  silent  alarms,  and  indicates  the  date,  bus  number,  driver 
number  and  supervisor’s  name  associated  with  the  silent  alarm  incident,  as  well 
as  whether  the  alarm  proved  to  be  real  or  false. 

The  "Arrest  Report"  (Figure  3-13)  lists  all  incidents  which  resulted  in 
arrest,  indicating  date,  incident  category,  time  of  arrest,  jurisdiction, 
muncipal  police  case  control  number,  and  case  disposition. 
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SILENT  ALARM  REPORT 

PAGE  NO.  1 

FROM  11/02/85  TO  11/06/85  07/15/86 

FROM  CATEGORY  05  TO  14 

FALSE  REAL 


CAT 

DATE 

DAY 

BUS  NO 

DRV  NO 

SUPERVISOR 

ALARM 

ALARM 

05 

11/05/85 

Tue 

1470 

0350 

DAVE  JONES 

0 

1 

12 

11/04/85 

Mon 

0906 

1551 

DEAN  SULLIVAN 

0 

1 

14 

11/03/85 

Sun 

0584 

1245 

BARB  GILMORE 

1 

0 

14 

11/04/85 

Mon 

0663 

0048 

JOE  O'REILLY 

1 

0 

14 

11/05/85 

Tue 

0832 

0000 

ROBERT  SMITH 

1 

0 

14 

11/06/85 

Wed 

0665 

1285 

MIKE  O'CONNOR 

1 

0 

TOTALS 

4 

2 

REPORT  COMPLETED  ! 

Press  any  key  to  continue... 


FIGURE  3-12.  SILENT  ALARM  REPORT 


ARREST  REPORT 


FROM 

11/08/85 

TO  11/13/85 

PAGE  NO . 1 

FROM 

CATEGORY 

01  TO  20 

07/15/86 

CAT 

CCN 

DATE 

TIME 

JURISDICTION 

DISPOSITION 

03 

85236332 

11/08/85 

06 : 28P 

MPLS 

ARRESTED 

03 

85237184 

11/09/85 

07 : 50P 

MPLS 

ARRESTED 

03 

85239860 

11/13/85 

07:20P 

SP 

ARRESTED 

10 

85236346 

11/08/85 

06 : 24P 

MPLS 

ARRESTED 

10 

85239896 

11/13/85 

08 : 29P 

MPLS 

ARRESTED 

10 

85239735 

11/13/85 

08 : 30P 

MPLS 

ARRESTED 

REPORT  COMPLETED  ! 

Press  any  key  to  continue... 


FIGURE  3-13.  ARREST  REPORT 
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3.2.4  File  Maintenance 


The  file  maintenance  menu  shown  in  Figure  3-14  allows  the  user  to  perform 
four  utility  operations:  backup,  restore,  archive  and  rebuilt  incident  index. 


FILE  MAINTENANCE 

0 - EXIT 

1 - BACKUP  INCIDENTS 

2 - RESTORE  INCIDENTS 

3 - ARCHIVE  INCIDENTS 

4 - REBUILD  INCIDENT  INDEX 
ENTER  YOUR  SELECTION  — 


FIGURE  3-14.  FILE  MAINTENANCE  MENU 


The  backup  incidents  function  allows  the  user  to  copy  data  from  the  hard 
disk  to  a floppy  disk  for  storage  purposes.  Because  hardware  failure  is  always 
possible,  it  is  advisable  to  have  data  backed  up  on  floppy  disks.  If  the  system 
should  ’’crash,"  data  on  the  hard  disk  might  be  lost,  but  could  be  retrieved  at 
a later  point  from  the  floppy  disk  backup  copy.  If  possible,  data  should  be 
backed  up  on  a daily  basis.  Since  there  is  limited  disk  storage  space,  the  user 
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must  be  cognizant  of  the  maximum  number  of  incident  records  that  an  individual 
disk  can  hold  so  as  not  to  overflow  disk  storage  space. 

The  restore  incidents  option  reverses  the  storage  functions  of  backup  by 
copying  data  from  a floppy  disk  back  onto  the  hard  disk.  This  option  can  be 

used  to  restore  backup  data  in  case  of  inadvertent  data  loss. 

The  archive  incidents  function  is  used  when  data  are  to  be  stored  on  a 
permanent  basis.  The  archive  option  allows  the  user  to  transfer  data  from  the 
hard  disk  to  a floppy  disk  and,  in  the  process,  to  erase  the  hard  disk  data. 
This  option  is  used  primarily  when  the  quantity  of  data  on  the  hard  disk  is  so 
large  that  it  is  slowing  down  processing  time  and  should  be  reduced.  In  such 
cases,  data  no  longer  in  active  use  are  "archived,"  that  is,  transferred  to 
floppy  disks  for  storage. 

The  final  menu  item,  the  rebuild  incident  index  option,  allows  the  user  to 
reconstruct  the  SIRS  index  files.  The  use  of  index  files  allows  the  program  to 
operate  in  a more  rapid  and  efficient  manner.  Index  rebuilding  is  necessary 
when  the  database  structure  has  been  changed  or  when  the  index  files  are 
inadvertently  damaged,  as  in  the  case  of  hardware  failure. 
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4.  CONCLUSIONS  AND  RECOMMENDATIONS 


4.1  GENERAL  APPLICABILITY  OF  SIRS 

Although  demonstrated  and  deployed  at  MTC,  SIRS  was  designed  to  be  flexible 
enough  to  meet  the  requirements  of  bus  systems  in  general.  For  systems  with 
characteristics  parallel  to  those  of  MTC,  SIRS  is  directly  transferable.  For 
transit  systems  with  different  characteristics,  SIRS  would  need  modification 
prior  to  implementation.  Some  pertinent  operational  characteristics  which  may 
vary  from  system  to  system  are  discussed  below. 

The  nature  of  patrol  activities  is  one  such  characteristic.  Because  MTC 
uses  on-board  patrols,  SIRS  aggregates  security  incidents  by  bus  route.  This 
aggregation  is  useful  in  deploying  security  forces  on  high-incident  bus  routes. 
However,  for  transit  systems  which  use  vehicle  patrols,  aggregation  of  security 
incidents  by  geographical  units  may  be  more  useful.  An  example  of  such  a system 
is  the  computerized  mapping  program  of  the  Southeast  Michigan  Council  of 
Governments  (SEMCOG) , which  aggregates  security  incidents  by  police  precinct. 

Another  variable  characteristic  is  the  procedure  used  in  reporting  security 
incidents.  The  four  reporting  forms  incorporated  into  SIRS  may  not  directly 
correspond  with  those  reporting  forms  used  by  other  transit  systems.  However, 
modifications  to  include  or  exclude  various  reporting  forms  can  easily  be 
accomplished . 

Finally,  transit  systems  vary  according  to  whether  they  patrol  bus  stops 
and  report  bus  stop  security  incidents.  Although  MTC  does  not  routinely  patrol 
bus  stops,  SIRS  includes  a special  code  indicating  that  an  incident  occurred  at 
a bus  stop  rather  than  on-board  a bus.  For  transit  systems  which  routinely 
patrol  bus  stops  or  which  receive  municipal  police  reports  on  bus  stop 
incidents,  this  data  could  represent  a large  percentage  of  reported  security 
incidents . 
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4.2  ENHANCEMENTS/MODIFICATIONS  TO  SIRS 


Due  to  the  reporting  procedures  in  use  at  MTC , SIRS  must  accomodate  input 
from  as  many  as  four  reporting  sources  (dispatcher,  driver,  security  officer, 
and  police  officer)  for  any  given  incident.  In  SIRS  as  demonstrated  at  MTC, 
there  is  no  control  number  linking  the  various  input  report  forms  based  on  the 
incident  they  describe.  Instead,  SIRS  matches  incoming  report  forms  using 
information  such  as  date,  bus  number  and  route  number.  This  method  can  result 
in  either  over-counting  or  under-counting  of  the  actual  number  of  incidents. 

Some  transit  systems  use  control  numbers  to  link  reports  corresponding  to  the 
same  incident,  and  SIRS  could  be  modified  to  accommodate  such  a control  number 
system.  In  fact,  the  use  of  such  a system  would  increase  the  accuracy  of  SIRS. 

At  MTC,  all  incidents,  security  and  nonsecurity  alike,  are  reported  on  the 
same  reporting  forms  and  are  included  in  the  SIRS  database.  An  advantage  of 
including  all  incidents  is  that  MTC  can  use  SIRS  to  aggregate  and  analyze 
safety-related  as  well  as  security-related  incidents.  SIRS  is  flexible  enough 
that  it  could  be  expanded  to  include  a safety  incident  reporting  system  in 
addition  to  the  current  security  incident  reporting  system.  On  the  other  hand, 
the  inclusion  of  nonsecurity  incidents  as  part  of  the  SIRS  database  slows  down 
the  operation  of  the  present  system. 

4.3  INDUSTRYWIDE  ISSUES 

Many  studies  in  the  transit  security  field  have  recommended  the  development 
of  a uniform  transit  crime  reporting  system  as  a necessary  step  in  improving 
transit  security  (Levine  and  Wachs,  1985;  Hargadine  and  Scott,  1985;  Mauri, 
Cooney  and  Prowe,  1984).  Uniform  statistics  would  allow  a more  accurate 
assessment  of  the  nature  and  scope  of  transit  security  issues  and  thereby  assist 
in  the  development  of  appropriate  countermeasures. 

An  important  step  toward  establishing  such  a uniform  transit  crime 
reporting  system  would  be  an  industry  consensus  on  how  transit  security 
incidents  should  be  categorized.  The  Uniform  Crime  Reporting  system  (UCR)  used 
by  police  departments  to  report  statistics  to  the  FBI  is  a good  starting  point. 
The  problem  with  the  UCR  system  when  applied  to  transit  security  incidents  is 
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two-fold:  1)  its  primary  emphasis  is  on  felony  crime  whereas  the  bulk  of  transit 
crime  consists  of  misdemeanors  and  local  ordinance  violations,  and  2)  the  UCR 
categorization  does  not  refer  specifically  to  the  transit  environment. 

In  recent  years  the  Southeast  Michigan  Council  of  Governments  (SEMCOG)  has 
developed  a transit  crime  categorization  which  modifies  the  UCR  system  to  make 
it  more  suitable  for  transit  application.  SIRS  does  not  incorporate  the  SEMCOG 
definitions  because  they  are  not  presently  used  at  MTC.  However,  SIRS  could  be 
modified  to  include  the  SEMCOG  classification  system. 

An  impediment  to  establishing  a uniform  transit  crime  reporting  system  is 
inconsistent  reporting  of  transit  security  incidents  on  the  local  level. 

Transit  system  personnel  do  not  always  report  incidents  which  they  observe,  and 
municipal  police  may  fail  to  inform  transit  agencies  of  security  incidents  which 
they  have  covered.  To  improve  the  reporting  practices  of  municipal  police,  it 
has  been  suggested  that  the  UCR  system  be  revised  to  include  transit  crime  as  a 
distinct  category  (Levine  and  Wachs,  1985).  Such  a revision  would  insure  that 
transit  security  incidents  currently  included  in  overall  crime  statistics  could 
be  separated  out.  In  addition  to  improved  police  reporting,  transit  systems 
must  improve  their  own  reporting  practices.  Better  communication  between 
transit  agencies  and  police  departments  with  regard  to  reporting  procedures 
would  also  improve  the  present  situation. 

Although  a computerized  system  such  as  SIRS  will  not  solve  these  problems 
in  and  of  itself,  it  can  act  as  a catalyst  to  prompt  better  reporting  practices 
by  transit  system  employees  and  municipal  police  departments. 

4.4  FUTURE  EFFORTS 

At  the  present  time,  SIRS  has  been  successfully  demonstrated  at  MTC  in 
Minneapolis/St.  Paul.  A similar,  more  sophisticated  system,  the  Advanced 
Transit  Crime  System  (ATACS) , has  been  developed  by  the  Southeast  Michigan 
Council  of  Governments  and  implemented  in  Detroit.  Future  efforts  should  be 
directed  toward  demonstrations  of  these  software  packages  at  other  transit 
systems  to  evaluate  their  general  applicability  and  utility.  While  these 
demonstrations  would  be  initiated  on  an  individual  basis,  some  form  of 
coordination  among  transit  systems  would  be  desirable.  Such  coordination  would 
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expedite  information-sharing,  and  thus  maximize  the  benefits  to  the  industry  as 
a whole.  Optimally,  these  demonstrations  would  also  address  improvements  in 
security  incident  reporting  practices  on  the  part  of  transit  systems  and 
municipal  police  departments,  as  well  as  the  development  of  a uniform  security 
incident  reporting  system  for  the  industry  as  a whole. 
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APPENDIX 

MTC  SECURITY  INCIDENT  REPORTING  FORMS 


A-1/A-2 


Form  890  - Rev  2/86 


o 


SPECIAL  SITUATION  REPORT  (SSR) 

(See  Reverse  Side  for  Instructions) 


CATEGORY  NUMBER 

CATEGORY  TITLE 

DATE, 

DAY 

TIME 

LOCATION  (CITY) 

LOCATION  (STREETS) 

BUS  NUMBER 

DRIVER  NUMBER 

ROUTE  NUMBER 

RUN  NUMBER 

DIRECTION 

GARAGE 

YES  NO 


( 1 ) Service  Lost?  What? 

( 2)  Service  Late?  Time? 

( 3)  Personal  Injury?  Who? 

( 4)  Damage  to  Property?  What? 

( 5)  Communications  used?  RRTT PRTT S/A Phone 

( 6)  Public  Safety  notified  Police  Fire Medic 

( 7)  Witness  Cards  requested?  

( 8)  Other  reports  requested?  Accident Incident Damage 

( 9)  Describe  situation  (who-what-when-where-why-how)  


(10)  If  police  report  made,  provide  Case  Control  Number  

(11)  Field  Supervisor  

(12)  Persons  Notified  

Report  Prepared  By Date 

FIGURE  A-1 . SPECIAL  SITUATION  REPORT 


A-3 


o 


SPECIAL  INCIDENT  REPORT  (SR) 

(See  Reverse  Side  for  Instructions) 


CATEGORY  NUMBER 


CATEGORY  TITLE 


DATE 


DAY 


TIME 


LOCATION  (CITY) 


LOCATION  (STREETS) 


BUS  NUMBER 

DRIVER  NUMBER 

ROUTE  NUMBER 

RUN  NUMBER 

DIRECTION 

GARAGE 

YES  NO 


( 1 ) Service  Lost?  What? 

( 2)  Service  Late?  Time? 

( 3)  Personal  Injury?  Who? 

( 4)  Damage  to  Property?  What? 

( 5)  Communications  used?  RRTT PRTT S/A Phone 

( 6)  Public  Safety  notified  Police  Fire Medic 

( 7)  Witness  Cards  requested?  

( 8)  Other  reports  requested?  Accident Incident  ___  Damage 

( 9)  Describe  situation  (who-what-when-where-why-how)  


(10)  If  police  report  made,  provide  Case  Control  Number  

(11)  Field  Supervisor  

(12)  Persons  Notified  

Report  Prepared  By Date 


FIGURE  A -2 . SPECIAL  INCIDENT  REPORT 


Metropolitan  Transit  Commission 

Security  Personnel  Duty  Report 

Saint  Paul  / Minneapolis  / Other (Circle  Correct  One) 

Time  Duty  Start TimeDutyEnd Page ol Pages 
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FIGURE  A-3.  SECURITY  OFFICER  DUTY  REPORT 


A-6 


FIGURE  A-3.  SECURITY  OFFICER  DUTY  REPORT  (CONTINUED) 


ARREST/CITATION  REPORT 

MINNEAPOLIS  POLICE  DEPARTMENT 

MPD  6006  RE6-83) 


CODE 


CASE  CONTROL  NO 


DATE  OE  ARREST 


TIME  OF  ARREST 


LOCATION  OF  ARREST 


PREC 


DATE  OF  CRIME 


TIME  OF  CRIME 


TRAFFIC  MISO  FELONY  WARRANT  CITIZEN  BOOKED  CITATION  NO 


CHARGES 


PRISONER  S NAME  (Firsl-Middle-Lasl) 


CHECK  IF  HISPANIC  □ 


008 


AGE  JUVENILE 


HOME  ADDRESS 


HOME  PHONE 


BUSINESS  ADORESS 


BUST  PHONE 


ALIASES/NICKNAMES 


OTHER  KNOWN  ADDRESSES 


OTHER  PHONE 


IF  JUVENILE.  PARENT'S  NAMES 


PARENT  S ADDRESS 


PARENT  S PHONE 


MAKE 


MODEL 


COLOR 


LICENSE  NO 


STATE  DRIVERS  LICENSE  NO 


STATE 


D WEAPON 

1 "REVOLVER 
2=  AUTOMATIC 
3=0THERH/GUN 
4=RIFLE 
S=SHOTGUN 
6=SAWED  S/GUN 
7=DISAB  CHEMICAL 


o 


8=KNIFE 

9=SHARP  INSTRU 
10- BLUNT  INSTR 
11  =EX  PLOSIVE 


MARITAL 

STATUS 

1- SINGLE 

2-  MARRIED 


a 


i RACE 

1=WHITE 
2=  BLACK 
3=  NATIVE  AMER 
4=CHINESE 
^JAPANESE 
6=  ASIAN 
7- ALAS  ESKIMO 
IUNKNOWN 


1 = MALE 
2=  FEMALE 


0 HEIGHT 

1=UNDER  54* 
2=5  5"  - 5 8’ 
3=5  9'  • S 
4=6  T - 6T 
5=0VER  6'3‘ 


Q WEIGHT 

1=UNDER  100* 
2=100  • 140 
3 = 140  - 160 
4=160  • 180 
5=180  • 200 
6=200  - 225 
7=0VER  2254 


O 


BUILO 


1 = THIN 
2=ME0IUM 
3=ST0CKY 
4=  MUSCULAR 
5=OBESE 


HANDED  0 OEFOmsifTtES 


@ HAIRSTYLE 


1=8ALD 
2=THINNING 
3=SH0RT 
4-SHLDR  LG 
5=AFR0  MED 
6- AFRO  LGE 
7=  PROCESSED 


8=CURLY 
9=STRAIGHT 
10  WAVEY 


0 HAJR  COLOR 

1=BLACK  8--WHITE 

?=BL0N0  9= FROSTED 

J=BROWN  10=0THER 

4=RED 

5=GRAY 

6=SANDY 

7 =SALT/ PEPPER 


0 WIG 


1=FULL 

2=PARTIAL 


o FACIAL  HAIR 

1-NONE 
2=UNS  HAVEN 
3=NEAT  BEARD 
4=FULL  BEARD 
5=SM  MUST 
6= LGE  MUST 


0 MASK 


1=FACE 

2=DISGUISE 

3=STXKING 

4=SKI 


0 TEETH 

1 = MISSING  UP 
2=MISSING  DN 
3=G0LD  UP 
4=GOLD  DN 
5=SILVER  UP 
6=SILVER  DN 
7=0THER 


© 


TATTOO 

1 = ARMS 

2=HAN0S 

3=FACE 

4=LEGS 

5=CHEST 

6=BACK 


1 =RIGHT 
2=LEFT 


1=FACE/HEAD 

2=EYES 

3= EARS 

4=HANDS 

5=ARMS 

6=LEGS 

7=TRUNK 


0 SPEECH 
1=REGI0NAL 
2=F0REIGN 
3=SOUTHERN 
4=STUTTER 
5=  LISP 

6=EFFEMINATE 

7=GRUFF 

8=OBSCENE 


0 


PHYSICAL/ 
MENTAL 

1=RETARDED 
2= EPILEPTIC 
3-PHYS  H'CAP 
4=SENILE 
5=DISTUR8ED 


NARRATIVE:  Give  detailed  account  of  offense  and  circumstances  leading  to  arrest 


ARRESTING  CITIZEN /COMPLAINTANT 

HOME  ADDRESS 

APART  NO 

PHONE 

CASE  CONTROL  NO 

WITNESS 

HOME  ADDRESS 

APART.  NO 

PHONE 

REPORT  MADE  BY  OTHER  ARREST/S  OFFENSE  STATEMENT/S 

REPORTS 

MAOE 

PROP  INV 

AUTO  IMPOUND 

ACTUAL  ARRESTING  OFFICERS/PERSONS  Store  Detectives  Railway  Police,  etc 

EMPL  NO 

SQO  NO 

CRIMINAL  HISTORY 


FIGURE  A-4.  MUNICIPAL  POLICE  INCIDENT  REPORT 
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